The present invention relates to systems and processes that support data communication between distributed computer systems. More specifically, the present invention is directed to a system and data processing method that enables the invocation of programs in a CICS transaction processing system on a remote computer as if they were stored procedures on a database management system.
A principal benefit of computers today is the storage of large quantities of data organized in a fashion that allows select portions of the data to be located quickly and presented either to the user or other programs. This is largely accomplished today by use of sophisticated software systems known as databases. A database provides facilities not only to store data, but also to provide enhanced searches to select entries and retrieve data items pursuant to the search protocols. In addition to direct access of the identified entries in the database, advanced features provide for data entries to be related to other entries so that relevant information is accessible in a profoundly manageable mechanism. The use of these facilities is generally referred to as querying a database.
Historically, various database system vendors developed their own languages to query database systems, and also their own application programming interfaces (APIs) by which programs communicated to these database systems. In the early 1980s, an effort by the computer industry to standardize the language by which databases are queried led to the adoption in 1986 of the Structured Query Language (SQL) by the American National Standards Institute. Somewhat later, an effort to standardize database APIs led to the issuance in 1992 of the Open DataBase Connectivity (ODBC) specification. This latter standardization effort was spearheaded by Microsoft Corporation, but quickly became widely adopted by all database system vendors.
The ODBC specification incorporates the SQL specification, by stipulating that all of the query commands to be sent to a database system through an ODBC-compliant API conform to the SQL specification. Both specifications are used almost universally for database access. Both have continued to evolve. The SQL specification was most recently revised in 1992. The ODBC specification is now at version 3.52, and was most recently revised in 1997.
As a result of the development of these two related standards, it is relatively easy for programmers to develop software to access data stored in database systems using programming techniques that are essentially independent of the vendor of the database system being accessed and, therefore, portable to other competing vendor products without substantial rewriting.
With reference to FIG. 1, a common feature of a database management system 102 is the ability to store a query in the database system itself, rather than in stored client database programs 103 or stored ODBC invocation programs 101 which access the database management system 102. Such queries are called stored procedures 106. Rather than a client data processing system 107 delivering a query to database management system 102, a stored ODBC invocation program 101 indicates to the database management system 102 the stored procedure 106 it wishes to have executed. A processing mechanism 104 at the database management system 102 executes the procedure, and delivers the result to a remote computer 100 of client data processing system 107 in the same manner as if the query were embedded in the stored client database program 103. Typical database management systems 102 also include one or more stored database management programs 110 and a database 108.
With reference to FIG. 2, transaction processing for businesses is another critically important function of modem computers. At first glance, there appear to be many similarities between the hardware configurations of FIGS. 1 and 2. For example, a typical transactional processing system 202 includes a processing mechanism 204, a database that stores transactional information 208, and one or more transactional programs 210. The foregoing environment relating to databases, as described in FIG. 1, was not, however, replicated in the field of transaction support software, and this field has developed without a common pool of standard protocols. In this context, a transaction is defined as a relatively brief interaction between a human being and a computer, where a human using an online terminal types some data and presses a key to request the computer to process that data.
Historically, transactional processing system vendors have developed their products without regard to one another. This has created an environment similar to that which originally existed with database management systems (FIG. 1), where a user or programmer had to learn the details of each vendor""s transactional processing system 202 in order to use it. A programmer working with a particular transactional processing system 202 was required to custom design-transactional programs 210 consistent with the vendor specific protocols for that transactional processing system 202. As a general matter, transactional programs 210 are executed by a processing mechanism 204, but software protocols may differ from vendor to vendor. If the same transactional program 210 was later to be used in conjunction with another transaction support product, the program would have to be modified to comply with the next vendor""s protocols. No standardization efforts have arisen to address these dissimilarities.
As in the case of a database management system 102 (FIG. 1), a transactional processing system 202 is intended for use with a client data processing system 207 that includes a remote computer 100 and a stored ODBC invocation program 201. Transactional processing system 202 also includes one or more stored client transactional programs 203. However, note that client data processing system 207 includes a display device 105. This is intended to illustrate the point that transactional processing systems are designed with the assumption that the consumer of is a human working at an online terminal, not another computer program. Some transactional processing systems, however, also offer interfaces which present their data in a manner suitable for further processing by another computer program. It is frequently the case that transaction processing systems access database systems (such as the system of FIG. 1) in order to store and retrieve data keyed in by human users. However, although a program in a transactional processing system will usually access databases through interfaces conformant to the ODBC and SQL standards, the manner in which the data is presented to the client data processing system 207 by the transactional processing system 202 generally does not conform to any vendor-neutral standard (as already stated above). Additionally, if a transactional processing system is accessing data not stored in a database system (FIG. 1), there are no standards that apply to such access.
The most widely used transaction processing system in the world today is a product of IBM, called CICS. CICS was introduced in the late 1960s, and has grown steadily in usage around the world. IBM can claim that nearly a billion transactions per day are processed through CICS systems. CICS is a registered trademark of IBM.
A number of existing systems are now offered to help support the communication with legacy programs by applying industry standard protocols. For example, Neon Systems, Inc., based in Sugarland, Texas has offered a product line of sophisticated middleware programs designed to facilitate communication to legacy programs. These products are discussed in the product brochure titled xe2x80x9cShadowDirect(copyright)xe2x80x9d and the product description titled xe2x80x9cAn Introduction to Shadow Directxe2x80x9d, both incorporated by reference as if restated in full.
The Neon System products fill an important need in the Industry. They, however, miss a critical capability in direct communication support to CICS programs that the present invention provides.
It is, therefore, an object of the present invention to provide a system that facilitates the access of CICS transaction systems to provide seamless transactional functionality.
It is another object of the present invention to provide a data processing method that seamlessly applies database standard protocols to perform operations in a CICS environment in a vendor neutral fashion.
It is still another object of the present invention to facilitate access to a transactional system having a proprietary API in a vendor neutral process using industry standard database protocols.
It is still another object of the present invention to process transaction operations as stored procedures independent of the protocols for the transaction system.
It is still another object of the present invention to provide seamless access to a CICS system while concurrently avoiding the 32.5 kbytes COMMAREA storage limit. COMMAREA is a registered trademark of IBM.
The above and other objects are realized in the form of a computer system that allows a programmer to create a program in IBM""s CICS system that appears to be a database stored procedure. The program can be invoked through an ODBC-compliant API, using a command conforming to the SQL standard. Likewise, the program""s results can be obtained through the same ODBC-compliant API. The present invention seamlessly manages the interaction between current client-based programs and CICS programs by implementing a data communication protocol. This is accomplished by incorporating a specifically configured driver as a dynamically linked library, termed here a TGADP DRIVER that manages the communication to the transaction software. TGADP is a registered trademark of Merrill Lynch and Co., Inc. This driver operates in conjunction with the transaction API to facilitate the transfer of the request to the transactional system and support the results reported by the transactional system back to the querying client program. This process makes it possible for software designed to invoke stored procedures through ODBC to be used to invoke CICS programs, even if that software was not originally conceived to do so. Thus, not only can custom applications be written to invoke CICS programs in this manner, but many ODBC-compliant programs may also be used, including such products as Microsoft""s Active Data Objects (ADO), MS Query tool, and Visual Basic for Applications (VBA).
The program so invoked can be an arbitrary CICS program, which may or may not access data in a database system. The program may access data in ordinary (xe2x80x9cflatxe2x80x9d) files, indexed (VSAM) files, or in databases not conformant to ODBC or SQL. The program may call or communicate with other programs, calculate results, and in fact do anything that a CICS program can do. If it chooses, the program may produce its results to appear as if they were data selected from a database (a xe2x80x9cresult set,xe2x80x9d in ODBC parlance).
In accord with the varying features of the present invention, the CICS program is invoked by this invention through an interface supplied by IBM called External Call Interface (ECI). This is IBM""s vendor-specific API provided to allow an application program which is not running under CICS to call an application program running under CICS. Besides being a non-standard interface, this ECI interface is limited to returning no more than 32,500 bytes of information from the CICS program. This invention overcomes that limit, through the implementation of a novel overflow mechanism. Without this innovation, application programs on both sides of the ECI interface must be programmed for the case where results may exceed 32,500 bytes, adding complexity to their implementations. Applying the inventive approach, application programs operate seamlessly without concern for the existence of this limitation.